Audio systems have long included individual components in separate housings. Since at least the 1950s, for example, a component stereo system might well include a tuner, amplifier, tape deck, and some sort of rotating media player. Sophisticated video systems have also long been “componentized”, so that a component video system might include a television linked with a VCR or DVD player, and a personal video camera or PVR.
Whether analog or digital, communication between such components has traditionally (i.e. prior to this invention) comprised a raw point-to-point data stream. A speaker, for example, merely accepts an analog signal from an amplifier. The information is assumed to be reliable, and there is no error checking, resending of information or the like. Even a DVD player sends raw data on an extension of its native bus.
Raw data transfer only works well when rigid standards are in place, the components are physically close together, and there are relatively few components being connected. Among other limitations, components that communicate using raw data transfer are only compatible if they are designed to talk with each other. Thus, a traditional video camera has to be designed to export a standard video or other signal that could be understood by a television. Similarly, older personal computers were always designed to export data to a printer using a RS-232 standard (serial port), or a Centronics standard (parallel port), because those are the communications standards that printers could understand.
The current trend is to communicate among components (also referred to as devices herein) using packets of information. In addition to the data being transferred, packets include header information such as type of data contained in the packet, i.e. HTML, voice, ASCII, etc., and origination and destination node information. The header information permits error checking, and routing across package switched networks such as the Internet between devices that may be widely spaced apart. The header information also allows extremely disparate devices to communicate with each other—such as a clock radio to communicate with a computer. Recently published US patent application no. 20020031086, (Welin, Mar. 14, 2002) refers to linking “computers, IP phones, talking toys and home appliances such as refrigerators, microwave ovens, bread machines, blenders, coffee makers, laundry machines, dryers, sweepers, thermostat assemblies, light switches, lamps, fans, drape and window shade motor controls, surveillance equipment, traffic monitoring, clocks, radios, network cameras, televisions, digital telephone answering devices, air conditioners, furnaces and central air conditioning apparatus.”
Interestingly, the idea of packet interconnectivity has never previously been applied to the level of elements within a device. All of the packet addressing in prior art devices has been performed between or among devices, as opposed to between or among elements within a given device.
Indeed, as used herein, the term “element” refers to a hardware unit that is a functional portion of a device, and traditionally communicates with other units of the same device across a bus, without having its own IP address. Where elements of a device communicate digitally, they have typically, but not necessarily, been located in a common housing, under the control of an operating system. In a traditional component video camera 10 of FIG. 1A, for example, a human interface 11, tuner 12, storage 13 (memory), and video decoder 14 all communicate across a memory bus 15, and are all contained within a common housing 16. The tuner uses data streaming or data blocks to talk to the storage, not packets. Similarly, in a traditional telephone enabled handheld computer (PDA), not shown, a telephone chip communicates with a memory chip and a CPU across a memory bus. The telephone chip uses data streaming or data blocks rather than packets to talk with the CPU.
Historically, it has made sense to use of data streaming or data blocks across a native bus to interconnect elements within the same component. Elements sharing the same physical box of a device are already designed to work together, they are physically close, and there are relatively few of them. Reliability across the bus is assumed, and speed is usually of paramount concern. Each of the elements can readily monitor the bus, and pull off whatever data it needs. There is no need to burden the device with packetizing the data to address individual ones of the elements with distinct, element-specific addresses.
In the past, elements within different devices have been able to talk with each other using packets, but only indirectly because the elements did not have their own IP addresses. For example, it is already known for an originating element (such as a disk drive) in a first device to use a native bus to send a data stream or series of data blocks to an IP packeting element in the same device, which packetizes the communication for transmission to a second device. But in such instances the second device must translate the packet back into a data stream of series of data blocks, and then send the information along its native bus to the receiving element (which may be another disk drive, display screen, or whatever). The packets are always directed to and from the devices. The originating and receiving elements never directly address each other using addresses in the packets.
A significant drawback of the prior art technology is that communication between elements that does use packets always goes through some sort of operating system. For relatively inexpensive devices, the cost of an operating system can be very significant, and in some instances prohibitive. These limitations hold true for the entire generation of “Internet ready” or “Web-enabled” appliances. In those devices, the prior art solution is to have the appliance send packets of information to a computer, which then stores or otherwise operates upon the information. This requires an operating system on some computer, either a local computer or a computer far away on the Internet. See, for example, Scenix' SX-Stack, described in “Scenix Debuts TCP/IP Embedded Chip For Internet Connectivity”, Computer Protocols, vol. 12, no. 11 (Nov. 1, 1999); Zilog's eZ80, described in “Zilog Sees New Lease of Life For Z80 In Internet Appliances”, Computergram International, No. 3751 (Sep. 21, 1999); and “Providing Network Connectivity For Small Appliances: A Functionally Minimized Embedded Web Server”, IEEE Commun. Mag., Vol. 39, No. 10 (October 2001).
Another result of the prior art technology is limited flexibility in choosing elements for inclusion in devices. The video camera of FIG. 1A is limited to the storage element(s) intended by the designers to be used with that camera. If a camera is designed to work with a flash card, the user cannot start using a re-writable CD ROM with his camera. Similarly, a television set top box is limited to the disk drives that are supported by its bus and operating system.
Still another result of the prior art technology is limited flexibility in disaggregating elements of a device. In the video camera example of FIG. 1A, the storage element is contained within the camera itself (although the storage medium may be removable) because the storage element is connected directly to the native bus. If a user wants to increase the storage, he either has to purchase a bigger memory card, or connect his camera to the bus of a computer. The camera cannot directly utilize storage that may be elsewhere in the room. In the case of television set top box, the tuner or cable decoder elements need to be in close proximity to the television.
Thus, there is a need for improved apparatus, systems, methods and protocols by which elements of electrical devices communicate with each other.